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Abstract: Asynchronous programming has appeared as a programming style that overcomes undesired properties 
of concurrent programming. Typically in asynchronous models of programming, methods are posted into a post 
list for latter execution. The order of method executions is serial, but nondeterministic. 

This paper presents a new and simple, yet powerful, model for asynchronous programming. The proposed model 
consists of two components; a context-free grammar and an operational semantics. The model is supported by 
the ability to express important applications. An advantage of our model over related work is that the model sim¬ 
plifies the way posted methods are assigned priorities. Another advantage is that the operational semantics uses 
the simple concept of singly linked list to simulate the prioritized process of methods posting and execution. The 
simplicity and expressiveness make it relatively easy for analysis algorithms to disclose the otherwise un-captured 
programming bugs in asynchronous programs. 
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1 Introduction 

All contemporary appliances (mobile, desktop, or 
web applications) require high responsiveness which 
is conveniently provided by asynchronous program¬ 
ming. Hence application program interfaces (APIs) 
enabling asynchronous, non-blocking tasks, such as 
web access or file operations) are accommodated 
in dominant programming languages. APIs provide 
asynchronous programming but mostly in a hard way. 
For example consider the following situation. A 
unique user interface (UI) task thread is typically used 
to design and implement user interfaces. Hence events 
on that thread simulate tasks that change the UI state. 
Therefore when the UI cannot be redrawn or respond, 
it get freezed. This makes it sensible, in order to keep 
the application responding continuously to UI tasks, 
to run blocking I/O commands and long-lasting CPU- 
bound asynchronously. 

Asynchronous programming has multi-threaded 
roots. This is so as APIs have been implemented using 
multi-threaded programs with shared-memory. Soft¬ 
ware threads execution is not affected by the number 
of processors in the system. This is justified by the 


fact that the threads are executed as recursive sequen¬ 
tial softwares running concurrently with interleaved 
write and reads commands. The many possible inter¬ 
leavings in this case cause the complexity of models 
of concurrent programming f8j|. In a complex process, 
atomic locking commands can be added for preven¬ 
tion and prediction of bad thread interleavings. The 
non-deterministic style of interleaving occurrence cre¬ 
ates rarely appearing programming-errors which are 
typically very hard to simulate and fix. This diffi¬ 
culty lead researchers to design multi-threaded pro¬ 
grams (of APIs) in the framework of asynchronous 
programming models |6j|7). 

The relative simplicity of asynchronous program¬ 
ming makes it a convenient choice to implement APIs 
or reactive systems. This is proved by recent years in¬ 
tense use of asynchronous programming by servers, 
desktop applications, and embedded systems. The 
idea of asynchronous programming is to divide cumu¬ 
lative program executions into tasks that are briefly¬ 
running. Moreover accessing the shared memory, 
each task is executed as a recursive sequential soft¬ 
ware that specifies (posts) new methods to be executed 
later. 


Many attempts were made to present formal asyn¬ 
chronous programming models. However few at¬ 
tempts f5| were made to express and formalize the 
fact that posted tasks in asynchronous programs may 
well have different execution priorities. A big disad¬ 
vantage of existing work (5| that considers execution 
priorities is the complexity of the models hosting such 
priorities. For example the work in (5| considers the 
execution priorities using several task-buffers which 
makes the solution a bit involved. 

This paper presents a simple, yet powerful, model 
for asynchronous programming with priorities for task 
posting. We call the proposed model Msynchp. The 
paper also presents a novel and robust operational se¬ 
mantics for the constructs of ylsynchp. A simple 
singly linked list of prioritized posted tasks is used to 
precisely capture the posting process. Our proposed 
asynchronous model is to simplify analyzing asyn¬ 
chronous programs fQ. 


Motivating Example 

A motivating example of designing our model comes 
form the way hardware interactions take place in oper¬ 
ating systems (more specifically in Windows) kernels. 
Concepts of prioritized interrupt sets are used to sim¬ 
ulate these hardware interactions in an asynchronous 
style. For such applications a simple, yet powerful 
and mathematically well founded, model for priori¬ 
tized asynchronous programming is required. 


Contribution 

The contributions of this paper are: 

• A prioritized asynchronous programming model; 
Msynch-p. 

• A novel operational semantics for *4synchp> pro¬ 
grams. 


Organization 

The rest of the paper is organized as follows. Section[2] 
presents the proposed prioritized asynchronous pro¬ 
gramming model - „4synchp>. The semantics of pri¬ 
oritized asynchronous programming model; .Asynch-p 
is shown in Section [3] which is followed by Section [4] 
that reviews related work and presents directions for 
future work. The last section (Section [5]) of the paper 
concludes it. 


2 Prioritized Asynchronous Pro¬ 
gramming Model 

This section presents our model, Asynchp, for prior¬ 
itized asynchronous programming. In pfsynch-p, each 
posted method has an execution priority. An asyn¬ 
chronous program execution is typically divided into 
quick-running methods (tasks). Tasks of higher pri¬ 
ority get executed first and task of equal priorities are 
executed using the first come first serviced strategy. 
Asynchronous programming has an important appli¬ 
cation in reactive systems where a single task must 
not be allowed to run too long and to prevent execut¬ 
ing other (potentially) highly prioritized tasks. 

Figure Q] presents the simple and powerful model 
Msynch-p for prioritized asynchronous programming. 
Considering single local and global variables and us¬ 
ing free syntax of expressions does not cause any gen¬ 
erality lose. However each expression is built using 
the global variable of the program and the local vari¬ 
able of the active method. A _4synchp> program P 
consists of a single global variable g and a sequence 
of methods denoted Mi, ..., M n . The Provided(e) 
statement continues executing the program provided 
that the expression e evaluates to a non-zero value. 

Each method M is expressed as a structure 
meth(m, l , S) of a method name, a single local vari¬ 
able l, and a top-level statement S. The sets of all pro¬ 
gram methods and statements are denoted by Meths 
and Stmts, respectively. Intuitively, the asynchronous 
call is modeled by the statement Synch(m(e),p) 
where: 

• the called method name is m, 

• the calling parameter is the expression e, and 

• the execution priority of this call is p. 

We assume three levels of execution priorities; 
{high(l), medium(2), low(3)}. 

3 Mathematical Framework for 

^4synchp 

This section presents a novel operational semantics 
for asynchronous programs built using Msynchp. Our 
semantics is based on a singly liked-list (which we call 
Asynchronous Linked List {ALL)) to host the posted 
methods. ALL is divided into three regions using 
pointers. The first, the middle, and last regions of ALL 
host posted methods that have high, medium, and low 
execution priorities, respectively. 

Definition Q] introduces formally the concept of 
( Asynchronous Node (AN)) to be used to build ALL. 



g G G = Global variable names. 

1 G L = Method local variable names. 

p G P = {high(l),medium(2),low(3)} 

= The set of all synchronization priorities. 

m G M s= The set of all method names. 

v G Val = the set of possible values of local and global variables. 

S £ Stats 

::= Si; S 2 | g := e \ l := e | Provided e | if e then St else Sf \ 


while e do S | run m(e) | return() | Synch(m(e),p). 

M G Meths 

::= meth (m,l,S). 

P G Programs 

■■■= program(< 7 , M*). 


Figure 1: yfsynch-p: a language model for a simple prioritized asynchronous programming. 


Definition 1 An asynchronous node (AN), n, is a sin¬ 
gle linked list node whose data contents are two loca¬ 
tions containing: 

• x\: a method name, and 

• X‘ 2 ,: a parameter expression. 

For a method call m(e) in a Asynchp program, we let 
Nodemie) denotes the asynchronous node whose lo¬ 
cations X] and X ‘2 contain in and e, respectively. The 
set of all asynchronous nodes is denoted by Nodes a. 

Definition [2] introduces formally the concept of 
Asynchronous Linked List (ALL) that is to be used to 
accurately capturing the semantics of the constructs of 
the proposed asynchronous model. 

Definition 2 An asynchronous linked list (ALL), 

li=< f,c,e h ,e m >, (1) 

is a singly linked list whose nodes are asynchronous 
nodes (in Nodes a) such that: 

• f is a pointer to the first node of the list, 

• c is a pointer to the current node, and 

• , e m are pointers to the last node in the list 
hosting a method of high and medium priorities, 
respectively. 

The set of all asynchronous linked lists is denoted by 

Lists a- 

Whenever a method gets posted, an asynchronous 
node is created and inserted into an asynchronous list. 
If the posted method is of priority h or m, the cre¬ 
ated node gets inserted after the nodes pointed to by 
eh or e m , respectively. If the posted method is of pri¬ 
ority l, the created node gets inserted at the end of the 


list. Whenever a posted method is to be executed, the 
method corresponding to the head of an asynchronous 
node is executed and that head gets removed form the 
list. These two operations are assumed to be carried 
out by the functions defined in Definition [3] 

Definition 3 Let li =< f,c,eh,e m > be a asyn¬ 
chronous linked list (in Lists a)- We let 

• add a '■ Nodes a xPx Lists a —>• Lists a denotes a 
map that adds a given node n of a given priority 
p after the node pointed to be li.e„ in a given list 

iE 

• remove a '■ Lists a —> Nodes a x Lists a denotes 
a map that removes the first node of a given list 
li and return the removed node and the resulting 
linked list. 

Definition |4] introduces the states of our proposed 
operational semantics. 

Definition 4 Let program (g, M\,..., M n ), where 
Mi = meth(rn t , li, Si), be a program in Asynch-p. An 
asynchronous program state (APS) is a triple (s,li,sk), 
where: 

• s is a partial map from G U (M x L) to Val. 

• li is an asynchronous linked list. 

• sk is stack of method names. 

We let Mi.l and Mid denote li and Sp respectively. 

Each semantic state is a triple of a partial map captures 
the contents of global and local variables, an asyn¬ 
chronous linked list, and a stack of method names. 

'Note that p G {h, m, l}. If p = l, ei is the last node in the 
list 




li' = add^(Node(m(e)),p, li) 
Synch(m(e),p)) : ( s,li,sk ) —» ( s,li',sk ) 
is-empty(sfc) = false sk' = pop(sfc) 


■(synch 8 ) 


■(return 8 


return() : (s, li, sk) —¥ (s, li, sk') 

m 1 = peek(sfc) v = \\e(s(g), s(m'.l)\\ s" = s[m.l i-r v\ 
sk" = push(sfc,m) m.S : (s",li, sk") —» (s',li!, sk') _ 

run m(e) : ( s, li, sk) —r (s', li', sk') 
m! = peek(sfc) v = \\e(s.g,m' .l)\\ 

0=S) 

(:=f) 

C V s ) 


(run 8 ) 


-( 

g := e : (s, li, sk) —> (s[<? i-r w], li, sk) 

m! = peek(sfc) 

v = \\e(s.g,m'.l)\\ 

l ~ e : (s, li, sk) —> 

(s[m '.1 t>], li, sk) 

m! — peek(sfc) 

\\e(s.g,m'.l)\\ 0 

t 

Provided e : (s, li, sk) —> (s, li, sk) 

m' = peek(sfc) 

\\e(s.g,m’,l)\\ = 0 

( 


K) 

while edoS: ( s, li, sk) —> (s, li, sk) 
m' — peek(sfc) \\e(s.g,m'.l)\\ ^ Q 

S : (s, li, sk) —» (s",li", sk") while e do S', (s", li", sk") —» (s ', li', sk') / « 

while e do S', (s, li, sk) —» (s', li', sk') 

m! = peek(sfc) \\e(s.g,m' ,l)\\ = 0 
Sf : (s,li,sk) —» (s',li',sk') _ 

if e then else Sf : (s, li, sk) —> (s', li', sk') 

m' = peek(sfc) \\e(s.g, m'.l)\\ ^ 0 
St : (s,li,sk) —» (s',li',sk') 


if e then S't else Sf : (s, li, sk) —> (s', li', sk') 

Si : (s,li,sk) (s",li" ,sk") S2 ■ (s",li", sk") (s',li',sk') 

Si; 62 : (s,li,sk) —» (s',li',sk') 


(; s ) 


Figure 2: Transition rules for statements. 


The stack is meant to keep the order in which methods 
call each other. 

Figures [2] and [3] present the transition rules of the 
proposed operational semantics. Some comments on 
the rules are in order. The rule synch 5 creates an asyn¬ 
chronous node corresponding to the method m and the 
parameter e. Using the map add_ 4 , the node then is 
added to the asynchronous list li to get the new list li'. 
The rule (return 5 ), pops an element from the method 
stack as the return statement means that the top ele¬ 
ment of the stack is executed. The rule (run 5 ) first 
peeks the first element of the stack to get the local vari¬ 
able (vn!.1) of the currently active method. This local 
variable is then used together with the global variable 
to evaluate the expression e. The resulting value is 
used to modify the local variable of the method (m) 
that is to be executed. Then m is pushed into the stack 
and the statement of m is executed. 


The rule (prog 5 ) first runs the statements of all 
methods of the program being executed then runs all 
statements of the methods that is posted. The posted 
statements are executed via the rules (=>f) and (=^|). 

4 Related and Future Work 

Parallel, distributed, reactive, and concurrent pro¬ 
gramming have been attracting much researcher activ¬ 
ities. The asynchronous programming methodologies 
include: 

• multi-threaded light-weight orchestration pro¬ 
gramming |fl9l . 

• thread Join-based allocation, 

• typed synchronous programming languages l l20l . 

• functional sensible programming, 














-(=>l) 

(s, empty, empty) => (s, empty, empty) 

( n,li') = remove^ (li) n.xi.S : (s, li', empty) —>• (s", li”, empty) 
(s", li”, empty) =>■ (s', empty, empty) _ 

(s,li, empty) (s', empty, empty) 

sk” = push(m, sk) S : (s, li, sk") —> (s', li', sk') 

-(meth s ) 

meth (m,l,S) : (s,li,sk) —> (s',li',sk') 

VI < i < n. Mi : (si,lii,ski) —> (si+i, lii+i, sk i+ i) 

_ (sn+i,U n +i, empty) =» (s', empty, empty) _( pro 

program(<7, Mi ,..., M„) : (si, Hi, ski) —> (s', empty, empty) 


Figure 3: Transition rules for methods and programs. 


• promises, and 

• co-methods and futures agents ll2Tl[22il . 

Event-based techniques for programming have been 
using continuations which are delimited monadic ifTTl 
M- Fork-join, task, async, and event functions appear 
not to rely on a specific language design. There is 
a big research debate about the relationship between 
threads and events in systems research ffl6l . 

In an asynchronous program, executions contain¬ 
ing context switches bounded by a user-specified limit 
are explored by context-bounded verification IT4I1T5 1. 
This context-bounding idea is not reasonable for pro¬ 
grams with big number of events. Several treatments 
for this problem have been proposed for this prob¬ 
lem. Without losing decidability, lfl3ll proposed a 
context-minimizing technique permitting unbounded 
context switches. For asynchronous concurrent pro¬ 
grams, in l fT2l . the round-robin technique for schedul¬ 
ing is used to enable unbounded context switches. 

Sequential techniques are also used to analyze 
asynchronous programs. In flT4ll . a source-to-source 
technique building sequential programs from multi¬ 
threaded programs was proposed via under approxi¬ 
mating the possible set of executions of the input pro¬ 
gram. A novel source-to-source transformation pro¬ 
viding for any context-bound, a context-bounded un¬ 
der approximation was presented in fTTTl . A main 
issue of the work in El is that the resulting se¬ 
quential program may host main states unreachable 
in the given asynchronous program. Other techniques 
like ifTOl treat this problem by repeatedly running the 
code to the control points where used-defined val¬ 
ued are needed. The work in @ compares the tech¬ 
niques of asynchronous programs verifications that 
use verification-condition-checking against that use 
model-checking. One major results of this work is that 
eager approaches outperforms lazy ones. The work 
in QD uses the construction using a bound on the task 


number, to reduce asynchronous programs into se¬ 
quential programs via priority-preemptive schedulers. 

The work presented in this paper is close to se- 
quentialization lfT4ll : the concept describing composi¬ 
tional reductions to get sequential programs from con¬ 
current ones. Although sequentialization started by 
checking multi-threaded programs with one context- 
switch, it was developed later to treat a user-specified 
number of context-switches. These switches occur 
among statically-specified group of threads running 
using RR order ifTTll . In 0, a technique for treat¬ 
ing context switches among an unspecified number of 
dynamically-created tasks was presented. This tech¬ 
nique (in 1121) hence explicitly treats event-oriented 
asynchronous programs. 

For future work, it is interesting to devise static 
analyses for asynchronous programs using the model 
Asyncbp |Q]|. Initial experiments show that our pro¬ 
posed model is expected to support devising robust 
and powerful analysis techniques. An examples of 
targeted analyses is dead-posting elimination which 
aims at removing the unnecessary posting statements 
from asynchronous programs. 


5 Conclusion 

Main reason to use asynchronous programming is 
to overcome some problems of concurrent program¬ 
ming. The main idea of asynchronous programming 
is to post methods into a post list for latter execution. 
The order of executing these methods is nondetermin- 
istically serial. 

A new and simple, yet powerful, model for asyn¬ 
chronous programming was presented in this pa¬ 
per. More precisely, the paper proposed a context- 
free grammar and an operational semantics for asyn¬ 
chronous programming. One important aspect of the 
proposed model is supporting posting methods with 







execution priorities. 
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